Skip to content

feat: add pg_cron container image#143

Open
ardentperf wants to merge 4 commits into
cloudnative-pg:mainfrom
ardentperf:pr-cron
Open

feat: add pg_cron container image#143
ardentperf wants to merge 4 commits into
cloudnative-pg:mainfrom
ardentperf:pr-cron

Conversation

@ardentperf
Copy link
Copy Markdown

pg_cron is an open-source extension that provides a simple cron-based job scheduler for PostgreSQL, allowing you to schedule PostgreSQL commands directly from the database.

Closes #139

pg_cron is an open-source extension that provides a simple cron-based
job scheduler for PostgreSQL, allowing you to schedule PostgreSQL
commands directly from the database.

Closes cloudnative-pg#139

Signed-off-by: Jeremy Schneider <schneider@ardentperf.com>
@ardentperf ardentperf requested review from a team and NiccoloFei as code owners March 16, 2026 23:23
@GabriFedi97 GabriFedi97 mentioned this pull request Mar 23, 2026
4 tasks
@gbartolini
Copy link
Copy Markdown
Contributor

Hi @ardentperf, now that we've resolved the version issue, could you please revisit your initial attempt? Let me know your thoughts, or we may need to close this PR since it has significantly diverged from the main branch, and it might be better/easier to submit a new one.

@gbartolini
Copy link
Copy Markdown
Contributor

@ardentperf, are you willing to contribute to this PR? Otherwise, I am closing this, as it has drifted a lot from the current specification. Thanks.

updated to post-cloudnative-pg#149/cloudnative-pg#154 metadata format: nested version objects with
package+sql versions, set cron.database_name so CREATE EXTENSION works
during E2E tests, enables create_extension

Signed-off-by: Jeremy Schneider <schneider@ardentperf.com>
@gbartolini
Copy link
Copy Markdown
Contributor

Can a disclaimer be added for the pg_cron extension? It should indicate that writable workloads will be executed locally on the primary instance, bypassing the service. In the event of a network partition or if the primary instance becomes isolated, these workloads will continue to write on the primary until it self-fences. It’s important to warn users about this.

@ardentperf
Copy link
Copy Markdown
Author

My own view is that CNPG should move toward making synchronous replication the default configuration (cf. cloudnative-pg/cloudnative-pg#10783 ) and failoverQuorum: true. in this configuration, core postgres ensures that no durable writes will be allowed by postgres at any time during a network partition - even from pg_cron jobs.

Kubernetes Services are a traffic routing mechanism, but IMO we shouldn't generally think of services as a fencing mechanism - they aren't intended for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[New Extension]: pg_cron

2 participants